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SERVICE DISCOVERY ACCESS TO USER LOCATION 

5 

BACKGROUND OF THE INVENTION 
Field of the Invention: 

10 

The invention disclosed broadly relates to methods for providing hitemet services and 
'B more particularly relates to improvements in mobile device accessing of Internet services while 
j= the services are linked to a user location. 

= 15 Background Art: 

1=^ Universal Description, Discovery and hitegration (UDDI) is a defacto standard for an 

Internet-based registry. The UDDI registry enables users to discover services and businesses on 
the Internet. The UDDI standard takes advantage of Worldwide Web Consortium (W3C) 

20 standards and hitemet Engineering Task Force (IETF) standards such as Extensible Markup 

Language (XML), Hypertext Transfer Protocol (HTTP), Domain Name System (DNS) protocol, 
and Simple Object Access Protocol (SOAP) messagmg protocol. The UDDI registry enables 
users to quickly, easily and dynamically find businesses and services on the hitemet. The UDDI 
registry enables businesses to reach their customers and partners with information about their 
25 products and Web services. The UDDI registry also enables businesses to integrate into each 

other's systems and processes. Registering enables a business to pubhcly list basic information 
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about its company and offerings. There is also the option to list a catalog of products, services 
and guidelines for engagement. Registered businesses and their catalogs of services and products 
are then accessible in searches by potential buyers. Details of the UDDI registry and its 
searching protocol can be found in the following online papers: 

UDDI Executive White Paper. September 6, 2000, 
http://www.uddi.org/pubs/UDDI_Executive_White_Paper.pdf 

UDDI Technical White Paper, September 6, 2000, 
http://www.uddi.org/pubs/Lii_UDDI_Technical_White_Paper.pdf 

UDDI Programer's API 1.0. UDDI Open Draft Specification 30 S eptember 2000. by 
Toufic Boubez, et al, http://www.uddi.org/pubs/ProgrammersAPI-Vl-l.pdf 

T [DDI Data Structure Reference. UDDI Open Draft Specif ication 30 September 2000, by 
Toufic Boubez, et al, http://www.uddi.org/pubs/DataStructure-Vl.pdf 

Mobile phones and wireless personal digital assistants (PDAs) are able to access the 
Internet using the Wireless Apphcation Protocol (WAP). The Nokia WAP Client Version 2.0 is 
a software product containing the components necessary to implement a WAP client on a 
wireless device. These components include a Wireless Markup Language (WML) Browser, 
WMLScript engine, Push Subsystem, and Wireless Protocol Stack. The Nokia WAP Ghent is a 
source-code product that can port and integrate into wireless devices such as mobile phones and 
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wireless PDAs. Application programs stored in the wireless device interact with the WAP Ghent 
to implement a variety of communications apphcations. Details of the Nokia WAP Ghent 
Version 2.0 can be found in the online paper: Nokia WAP Ghent Version 2.0, Product Overview , 
Nokia hitemet Communications, 2000, www.nokia.com/corporate/wap. 

What is needed is the abihty of a mobile phone or wireless PDA to discover hitemet 
businesses and services by accessing the UDDI registry. It would be even more useful to 
facihtate the formation of a query to the UDDI registry for the wireless device user. It would be 
beneficial to maintain a personal profile of the user's hitemet accessing preferences and to use 
that profile in formulating a detailed UDDI query of the UDDI registry from the user's 
abbreviated inputs to the wireless device. 

In addition to discovering Internet and business services via UDDI, there is a further need 
to tailor business/service discovery to a particular geogrphic region or location. Coupled with 
existing locating technologies (e.g.. Global Positioning System (GPS)), service discovery maybe 
enabled to serve users with geographical interests. Through the use of user profiles, preferences, 
and/or handles, a geographically focused UDDI search may be implemented on a wireless device 
with relative speed and convenience. 

SUMMARY OF THE INVENTION; 

In accordance with the invention, a method is disclosed to enable a mobile phone or 
wireless PDA to discover Internet businesses and services in a specified geographical location by 
accessing the Universal Description, Discovery and Integration (UDDI) registiy. The method 
facilitates the formation of a query to the UDDI registiy for the wireless device user. The query 

Case 28464 3 

4208-4010 

24286 vl 



is typically appended with a user location. The location may be automatically inserted through a 
locating device, or may be inputted manually by the user. The method constructs a personal user 
profile of the user's UDDI searching strategies and hitemet accessing preferences. The user 
profile can be used as a shortcut for onhne or offline queries to the UDDI registry or for 
5 accessing pages from web sites, in response to the user's entry of abbreviated inputs to the 

wireless device. The method also includes a user location profile, in which the user may store or 
otherwise indicate geographical preferences. The location profile can also be used as a shortcut 
for queries. The method is embodied as programmed instructions which may be executed within 
the user's wireless device to query the UDDI registry. Alternately, a method is embodied as 
% programmed instructions that may be executed within a separate knowledge engine server to 
!i ! query the UDDI registry in response to commands from the user's wireless device. The server 

can be used to cache files accessed from web sites, for selective forwarding to the user's wireless 
yi device. 

!ii hi one aspect of the invention, the sequence of operational steps for the wireless device's 

' 1 5 UDDI registry browsing method begins by entering a search handle that will be associated with 
the user's search strategy. The user may additionally specify a geographic location, or have the 
wireless device transmit a geographical coordinate. The query terms are then entered by the user, 
which may be a business name, part of a business name, a service description, or other 
characterization. If the user wishes to focus the search to a geographic location, the query will 
20 then be linked with the geographic location prior to, or sent along with the geographic location 
during transmission. If the characterization is part of a business name, the wireless device then 
sends afindjusiness XML inquiry using Simple Object Access Protocol (SOAP) to the UDDI 
registry with the appended location. The wireless device then receives back from the UDDI 
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registry, a husinessList message that contains a list of business names satisfying the 

find business query under the specified location. The user can then select an item from the 

returned businessList message and drill-down in the selected business' entity data. 

The wireless device then sends a find_service XML inquiry using SOAP to the UDDI 
5 registry with the appended location. The wireless device then receives back from the UDDI 
registry, a serviceList message that contains a Hst of names of services offered by the selected 
business. The user can then select an item from the returned serviceList message and drill-down 

in the selected service data, 
fl The wireless device then sends a _get_serviceDetail_ XML inquiry using SOAP to the 

jjo UDDI registry. The wireless device then receives back from the UDDI registry, a serviceDetail 
i I message that includes bindingTemplate data that contains the details of the selected service. 

The list of service details may be sent according to an established hierarchy, or may alternately be 
J1 sent without a specified regiment or priority, hicluded in the bindingTemplate data is the 
i! accessPoint URL, which is the URL of the selected service on the web site of the selected 
15 business. 

The wireless device then displays the accessPoint URL to the user. The wireless device 
also stores the search handle in user profile with the selected accessPoint URL, to enable the user 
to access web pages from the web site of the selected business. This provides the user with a 
shortcut for accessing pages from web sites, in response to the user's entry of abbreviated search 
20 handle to the wireless device. 

The wireless device also stores the search and/or location handle in user profile with the 
UDDI registry search strategy. The stored location maybe an address, region, landmark, GPS 
location, triangulated location or other means capable of identifying a geographic location. The 

Case 28464 5 

4208-4010 

24286 vl 



stored search strategy includes the business name query , the selected businessEntity data, the 
selected businessService data, the selected bindingTemplate data, and the selected accessPoint 
URL. This provides the user with a shortcut for online or offline queries to the UDDI registry, in 
response to the user's entry of abbreviated search handle to the wireless device. The user may 
5 also opt to save only the query term, in order to search a particular class of businesses that may 
be geographically independent of each other (i.e., regional businesses). The search handle and/or 
locator handle may also be associated with a graphical icon on the user's screen, so the user may 
access the handles with greater efficiency. 
=lj To replay a UDDI registry search strategy, the user merely enters a search handle into the 

' jjO wireless device and selects the replay option. The wireless device then accesses the UDDI 
% I registry search strategy firom user profile corresponding to the search handle and loads the 

business name query , the selected businessEntity data, the selected businessService data, and the 
U1 selected bindingTemplate data as each respective operand that would have been otherwise 
■i! entered by the user. If the data in the UDDI registry has been updated since the user's last query, 
^ts the bindingTemplate data may contain additional or modified accessPoint URLs, of the selected 
service on the web site of the selected business. 

To replay a regional UDDI search strategy, the location handle is entered along with the 
saved query terms. The saved query terms may be entered independently, or may be stored 
under a search handle. Once the location handle and saved query are entered, the replay option 
20 may then be selected. Once selected, the wireless device then accesses the UDDI search strategy 
and location firom the user profile and loads the business name query. The device then appends 
the location to the query and transmits the search. Under this embodiment, specific query terms 
may be combined with varying locations or location handles. 
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In another aspect of the invention, the sequence of operational steps described above for 
the wireless device's UDDI registry browsing method can also be carried out in a separate 
knowledge engine server. The server performs the above described method to query the UDDI 
registry in response to commands from the user's wireless device from a specified location. The 
5 knowledge engine in the server begins by receiving user's location and query or search handle. If 
a search handle has been received, then the server replays a corresponding search strategy for the 
UDDI registry accessed from the user's profile and uses the query steps specified in the strategy 
instead of requesting fiulher inputs from the user. If a location handle has been received, the 
server may replay the search under the specified location handle. 
■ jb If, however, the knowledge engine server has received a new user query, the server then 

I accesses the UDDI registry using the method described above to identify web sites in accordance 
, " to the user location. The server returns a hst of web sites to the user and stores binding templates 
1=1 in the user's profile. The server then receives the user's selection of web sites to search and the 
Hi server updates user profile with these preferences. 
5 Whether the server begins by receiving the user's new query or the user's search handle, 

the server proceeds to search the identified web sites using the URLs contained in the stored 
binding templates. The server retrieves any documents resulting from the search of the specified 
web sites. The server applies a filter that is prescribed by the user and stored in the user's profile, 
to Umit the returned documents to only those of particular interest to the user. The server sorts 
20 the documents in a list having an order estabUshed in accordance with user's profile. The server 
further stores the filtered documents and the sorted Ust in a cache for later use. The documents 
may subsequently be accessed selectively by the user. The server also returns the list of 
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documents to user, and if the user is not logged on, the list will be returned to the user when 
he/she next logs on. 

The server receives the user's selections from the hst and it updates the user's profile with 
the user's preferences. The server then returns the selected documents to user. As was described 
above, the knowledge engine server associates the search handle with user's selections and with 
the user's search strategy, storing that association in user's profile. Similarly, the user's last 
registered or entered location is stored and updated in the user's profile. Thus, any subsequent 
queries may be adjusted to a user location. 

DESCRIPTION OF THE FIGURES: 

Figure 1 is a network diagram of the invention, showing an exemplary relationship 
between the user's GPS Wireless Apphcation Protocol (WAP)-enabled portable wireless device, 
the WAP protocol gateway to the Intemet, the knowledge engine server, the Universal 
Description, Discovery and Integration (UDDI) registry, and a plurality of web sites; 

Figure lA through IH show the user's wireless device in a progression of stages as it 
carries out a location-specific UDDI registry browsing method; 

Figure II and 1 J show the user's wireless device in a progression of stages as it carries 
out the method of replaying a location-specific UDDI registry search strategy as a shortcut for 
online or offline queries to the UDDI registry; 
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Figure 2 is a functional block diagram of the wireless device 100, showing its various 
components and programs; 

Figure 2 A is a flow diagram of the sequence of operational steps for the wireless device's 
5 location-specific UDDI registry browsing program; 

Figure 2B is a flow diagram of the sequence of operational steps for the wireless device's 
program to replay the location-specific UDDI registry search strategy; 

% Figure 3 A is a network process flow diagram of the interaction of the wireless device and 

!i I the UDDI registry when carrying out the location-specific UDDI registry browsing program of 
Figure 2A; 

■:: Figure 3B is a network process flow diagram of the interaction of the wireless device and 

^ts the UDDI registry when carrying out the program to replay the location-specific UDDI registry 
search strategy; 

Figure 4 is a functional block diagram of the knowledge engine server, showing the 
memory storing the application services software programs needed to perform the operations of 
20 the invention; 

Figure 4 A is a more detailed functional block diagram of the server, showing the 
knowledge engine; 
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Figure 4B is a network process flow diagram of the interaction of the wireless device, the 
knowledge engine server, and the UDDI registry when carrying out the UDDI registry browsing 
program in the server. 

Figure 5 illustrates the location-based service discovery of web services and ad-hoc 
networking environments with additional Bluetooth™ capabilities. 

Figure 6 discloses location standardization in a network framework 

DISCUSSION OF THE PREFERRED EMBODIMENT; 

The invention is apphed to wireless telephones and wireless personal digital assistants 
(PDAs) implementing the Wireless Application Protocol (WAP) standard. Figure 1 is a network 
diagram of an embodiment of the invention, illustrating a relationship between the user's 
Wireless AppHcation Protocol (WAP)-enabled portable wireless device 100, a WAP protocol 
gateway 120, and the server 140. The user's WAP-enabled portable wireless device 100 can be a 
wireless mobile phone, pager, two-way radio, smartphone, personal communicator, or the like. 
The wireless device 100 may also be enabled with a GPS antenna 113, which provides user 
location information along with the service discovery request. It is understood that while an 
integrated GPS antenna is illustrated, a variety of user-location devices or techniques maybe 
employed to estabhsh user locations (e.g., radio beacon triangulation sensor, Bluetooth™ 
devices, etc.). An example may be found in European Patent EP 0 767 594 A2, entitled "Mobile 
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station Positioning System." Additional information on Bluetooth™ communication is provided 
in a book by Nathan J. MuUer entitled "Bluetooth Demystified", pubhshed by McGraw Hill, 
2000 (ISBN 007-1363238). Furthermore, while the embodiments disclosed below are based in a 
WAP environment, is also understood that the function and execution of the present invention is 
5 obtainable under other wireless protocols as well (e.g., XHTML) 

The user's WAP-enabled portable wireless device 100 accesses a small file called a deck 
which is composed of several smaller pages called cards which are small enough to fit into the 
display area of the device's microbrowser 102. The small size of the microbrowser 102 and the 
small file sizes accommodate the low memory constraints of the portable wireless device 1 00 and 
% the low-bandwidth constraints of a wkeless network 1 1 6. The cards are typically written in the 
11 1 Wireless Markup Language (WML) which is specifically devised for small screens and one-hand 

navigation without a keyboard. The WML language is scaleable fi-om two-line text displays on 
W the microbrowser 102 of a cellular telephone, up through large LCD screens found on smart 
S phones and personal communicators. The cards written in the WML language can include 
'1 5 programs written in WMLScript, which is similar to JavaScript, but makes minimal demands on 
memory and CPU power of the device 100 because it does not contain many of the unnecessary 
functions found in other scripting languages. The Nokia WAP Ghent Version 2.0 is a software 
product containing the components necessary to implement a WAP cUent on a wireless device. 
These components include a Wireless Markup Language (WML) Browser, WMLScript engine, 
20 Push Subsystem, and Wireless Protocol Stack. The Nokia WAP Client is a source-code product 
that can port and integrate into wireless devices such as mobile phones and wireless PDAs. 
Application programs stored in the wireless device interact with the WAP Ghent to implement a 
variety of communications apphcations. Details of the Nokia WAP Client Version 2.0 can be 
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found in the online paper: Nokia WAP Client Version 2 .0. Product Overview, Nokia Internet 
Communications, 2000, www.nokia.com/corporate/wap. 

The user's WAP-enabled portable wireless device 100 communicates with the radio tower 
114 and can exchange messages for distances up to several kilometers. The types of wireless 
5 networks 116 supported by the WAP standard include Cellular Digital Packet Data (CDPD), 
Code-Division Multiple Access (CDMA), Global System for Mobile Communications (GSM), 
Time Division Multiple Access (TDMA), GPRS, 3G-Broadband, and the like. As mentioned 
previously, the wireless device is further enabled to determine user location via the GPS antenna 
^fl 113. The device may alternately possess location capabilities through base station triangulation, 
% connection through a Bluetooth™ net (both of which are well-known in the art), or any 
il 1 equivalent means. A service discovery agent may also be invoked, where the agent would 

request location coordinates from a location server using a Location Forum (LIF) Application 
Program hiterface (API) (see http:\\www.locationforum.org). 
if! The overall process of communication between the user's WAP-enabled wireless device 

'Is (the chent or user) 100, through the WAP protocol gateway 120, to the server 140 resembles the 
way Web pages are served on the Internet using the HyperText Transfer Protocol (HTTP) or 
World Wide Web protocol: 

[1] The user presses a key on the user's device 100 related to the Uniform Resource 
Locator (URL) of the server 140. 
20 [2] The user's device 100 sends the URL, via the radio tower 1 14 and the wireless 

network 116, to the gateway 120 using WAP protocols. 
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[3] The gateway 120 translates the WAP request into an HTTP request and sends it over 
the Internet 130 to the server 140, via Transmission Control Protocol/ Internet 
Protocol (TCP/IP) interfaces. 

[4] The server 140 handles the request just like any other HTTP request received over the 
Internet. The server 140 either returns a WML deck or a HyperText Markup Language 
(HTML) page back to the gateway 120 using standard server programs written, for 
example in Common Gateway Interface (CGI) programs, Java servlets, or the like. 

[5] The gateway 120 receives the response from the server 140 on behalf of the user's 
device 100. If the response is an HTML page, it gets transcoded into WML if 
necessary. Then the WML and WMLScript coding is encoded into a byte code that is 
then sent to the user's device 100. 

[6] The user's device 100 receives the response in the WML byte code and displays the 
first card in the deck on the microbrowser 102 to the user. 

In Figure 1, the protocol gateway 120 includes a WAP protocol stack organized into five 
different layers (not shown). An application layer is the wireless application environment, which 
executes portable applications and services. A session layer is the wireless session protocol, 
which suppUes methods for the organized exchange of content between chent/server 
apphcations. A transaction layer is the wireless transaction protocol, which provides methods for 
performing rehable transactions. A security layer is the wireless transport layer security, which 
provides authentication, privacy, and secure comiections between apphcations. The transport 
layer is the wireless datagram protocol, which shelters the upper layers from the unique 
requirements of the diverse wireless network protocols, such as CDPD, CDMA, GSM, etc. 
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Additional information about the WAP standard and the WAP protocol stack can be found in the 
book by Charles Arehart, et aL entitled, "Professional WAP", published by Wrox Press Ltd., 
2000 (ISBN 1-861004-04-1). 

In Figure 1, the user's portable wireless device 100 includes the microbrowser 102 
5 displaying the Mobile Web Services menu, that enables the user to navigate through the cards 
being displayed and to select options that are programmed by the application programs 106. The 
usefs device 100 also includes the WAP client program 108 which has been previously 
discussed. Additionally, the wireless device is equipped with a keypad 104 which may be a 
Jff alphanumeric keypad, a "QWERTY" keypad, or any other keypad layout that may be proprietary 
ib to the device being used. Typically the keypad will possess a "Send" key which may be used to 
m initiate transmission. Additionally, a "Loc" key is preferably disposed on the keypad to allow a 
- user to efficiently register the location of the user and append the location to a subsequent query. 

Typically, the "Loc" key is communicatively coupled with the locating means (e.g., GPS), 
JiJ wherein the depression of the "Loc" key stores the user coordinates in a current geographic 
15 locator 107, The coordinates may subsequently be appended to UDDI search requests. The 

location may also be stored into a user preference list 105, wherein various user locations may be 
recalled. 

The Mobile Web Services menu displayed by the microbrowser 102 in Figure 1 is 
rendered by the WAP client program 108 under the control of the application programs 106, 
20 which are further illustrated in Figures 2, 2A, and 2B. The user can select the session type 

utiUzing the Mobile Web Services menu, by either [A] a direct session with the UDDI registry or 
[B] an indirect session with the UDDI registry through a knowledge server 140. The direct 

session with the UDDI registry is further illustrated in the network process flow diagrams of 
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Figures 3A and 3B. The indirect session with the UDDI registry through the knowledge server 
140 is further illustrated in the network process flow diagram of Figure 4B. Whichever session 
type is selected by the user, the Mobile Web Services menu of Figure 1 presents to the user the 
UDDI Registry Search Menu from which the user can select the following options: 

[1] USER QUERY REQUEST 

[2] USER LOCATION 

[3] DRILL-DOWN UDDI DATA FOR DETAILS 
[2A] BUSINESS ENTITY DATA 
[2B] BUSINESS SERVICE DATA 
[2C] BINDING TEMPLATE DATA 
[2D]T_M0DELDATA 

[4] INVOKE WEB SITE W/ CACHED UDDI DATA 

[5] ENTER SEARCH/LOCATOR HANDLE TO USE 
PROFILE FROM A PRIOR SEARCH 

Option [1] of user query request involves query terms for browsmg the UDDI registry for 
web site URLs. This browsing allows the user to explore and examine data organized by the 
UDDI registry in a hierarchy. The core information model used by the UDDI registries is defined 
in an XML schema. XML allows hierarchical relationships to be described for four types data: 
business information; service information, binding information; and information about 
specifications for services. 

A first type of data is business information, which is specified in the UDDI registry with 
the businessEntity XML element. The businessEntity XML element typically includes the name, 
general description, contacts, and categories of the business whose web site is on the Web. The 
businessEntity XML element serves as the top of the information hierarchy for all of the 

information about a business under the present embodiment. 
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A second type of data is Service information, which is specified in the UDDI registry 
with the businessService XML element. One or more businessService XML elements is 
contained in each businessEntity XML element. The businessService XML element includes one 
or more bindingTemplate XML elements, which are a third type of data. The businessService 
XML element is a descriptive container that is used to group a series of related Web services 
related to either a business process or category of services, such as purchasing services, shipping 
services, news services, and other high-level business processes. The businessService XML 
element information sets can each be further categorized in combinations of industry, product 
and service or geographic subjects. 

The bindingTemplate XML element contains the detailed technical descriptions of Web 
services. As such, these structures provide the technical entry point URL for specific services 
and products offered by a business. Each bindingTemplate XML element structure has a single 
logical businessService XML element parent, which in turn has a single logical businessEntity 
XML element parent. An important piece of information in the bindingTemplate XML element 
is the accessPoint element. The accessPoint element is the URL of a specific service provided 
by the business. A single attribute is typically provided, and is identified in the present 
embodiment as URLType. The purpose of the URLType attribute is to facilitate searching for 
entry points associated with a particular type of service. An example might be a purchase order 
service that provides three entry points, one for HTTP, one for SMTP, and one for FAX ordering, 
hi this example, a businessService XML element contains three bindingTemplate XML element 
entries, each with identical data with the exception of the accessPoint value and URLType value. 

A fourth type of data in the UDDI registry is the tModel XML element, which is pointed 
to by a pointer in the bindingTemplate XML element. The tModel XML element specifies the 
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protocols, interchange formats and interchange sequencing rules for accessing web pages from 
the business' server having the service information specified in the business Service XML 
element. 



Option [1] of the Mobile Web Services menu of Figure 1, is: 
[1] USER QUERY REQUESTS 



Option [1] for the user query request of browsing the UDDI registry for web site URLs 
involves starting with some broad information, appending a locator, performing a search, finding 
general result sets for that location and then selecting more specific information for drill-down. 
The UDDI registry accommodates the browse pattern with the findjcx API call. These calls form 
the search capabilities provided by the UDDI registry and are matched with return messages that 
return overview infomation to match the supplied search criteria. A typical browse sequence 
may involve finding whether a particular business has any information registered in the UDDI 
registry. This sequence would start with a call find Justness, and may subsequently pass the first 
few characters of the businesses name. The UDDI registry would then return a businessList 
result. The businessList resuh is a list of overview information (keys, names and description) of 
the businessEntity information that matched the search results returned by ihcfindjjusiness 
query. Figure 1 A through IH illustrate the user's wireless device in a progression of stages as it 
carries out the UDDI registry browsing method. Figure 2 A illustrates a flow diagram of the 
sequence of operational steps for the wireless device's UDDI registry browsing program. Figure 
3 A illustrates a network process flow diagram, showing the interaction of the wireless device and 
the UDDI registry when carrying out the UDDI registry browsing program of Figure 2 A. 
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Option [2] of the Mobile Web Services menu of Figure 1, is: 
[2] USER LOCATION 



5 When the user activates the wireless device under the present invention, the user may 

specify for the wireless device to enable user location identification. Alternately, the user may 
manually specify a location into the wireless device firom which the queries will focused to (an 
example of the location initiation can bee seen m Figures lA-B). A user service profile may be 
A? associated with the user preference list 105, and may be subsequently updated via the geographic 
Ji) location 1 07 of the user. The location information may be automatically appended or pasted into 
5] the search under the present invention to a user location input field. The system may be further 
enabled with macros to tailor geographic searches according to items such as street address, zip 
code, telephone area code/number, city, country, geographic region or even unique landmark 
S location (e.g., Eiffel Tower, Empire State Building, Golden Gate Bridge, etc.) 

Is 

Option [3] of the Mobile Web Services menu of Figure 1, is: 

[3] DRILL-DOWN UDDI DATA FOR DETAILS 
[3A] BUSINESS ENTITY DATA 
[3B] BUSINESS SERVICE DATA 
20 [3C] BINDING TEMPLATE DATA 

[3D]T_M0DELDATA 

After the user has identified a business he/she has been browsing for in Option [1], along 
with the location [2], the user can drill-down into their business Service information. Here, the 
25 user may search for particular service types for the location (e.g. purchasing, shipping, news and 

Case 28464 18 
4208-4010 

24286 vl 



the like) using the find_service API call. Similarly, if the user knows the technical fingerprint 
{tModel signature) of a particular product and wants to see if the business he/she has chosen 
supports a compatible service interface, the user can use the find-binding API call. 

Once the user has a key for one of the four main data types managed by the UDDI 
registry, he/she can use that key to access the full registered details for a specific data type 
{businessEntity, businessService, bindingTemplate, or tModet). The full registered information 
for any of these structures can be accessed by passing a relevant key type to one of the getjcx 
API calls to the UDDI registry. 

Contmuing with the example on browsing, one of the data items returned by all of the 
findL-xx return sets is key information. In the case of a business that the user is interested in for 
that location, the businessKey value returned within the contents of a husinessList structure can 
be passed as an argument to the UDDI registry to getJbusinessDetail. The successful return of 
this message is a businessDetail message containing the full registered information for the entity 
whose key value was passed. This typically will be a full businessEntity structure. Since full 
businessEntity structures can contain a large quantity of information, it can be optionally cached 
in the cache 144 of the knowledge engine server 140 of Figure 1. 

Option [4] of the Mobile Web Services menu of Figure 1, is: 
[4] INVOKE WEB SITE W/ CACHED UDDI DATA 

After the user has retrieved the businessEntity structure from the UDDI registry 170 of 
Figure 1, the user can access the access? oint element of the bindingTemplate XML element in 
the businessEntity structure to obtain the URL of a specific service provided by the business. 
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Option [4] invokes the business' web site 160 with the cached URL to access the desired web 
pages. Since the accessed web pages from the web site 160 can contain a large quantity of 
information, it can be optionally cached in the cache 144 of the knowledge engine server 140 of 
Figure 1. Furthermore, if the bindingTemplate is used to contact services directly at the 
5 accessPoint, and a failure occurs, the terminal will typically use the bindingTemplate ID to fetch 
new bindingTemplate information from the UDDI registry, assuming that the new information is 
up-to-date in relation to the service. 

Option [5] of the Mobile Web Services menu of Figure 1, is: 
% [5] ENTER SEARCH/LOCATION HANDLE TO USE PROFILE FROM A PRIOR 

lij SEARCH 

^ Option [5] enables the user to replay a prior UDDI registry search strategy and/ or 

!£ bcation. The user typically enters a previously used search or location handle into the wireless 
'''l 5 device and selects the replay Option [5] . The wireless device then accesses the UDDI registry 
search strategy from the user's stored profile corresponding to the search handle and loads the 
business name query, the selected businessEntity data, the selected businessService data, and the 
selected bindingTemplate data as each respective operand that would have been otherwise 
entered by the user. If the data in the UDDI registry has been updated since the user's last query, 
20 the bindingTemplate data may contain additional or modified accessPoint URLs, of the selected 
service on the web site of the selected business. Figure II and IJ illustrate the user's wireless 
device in a progression of stages as it carries out the method of replaying a UDDI registry search 
strategy as a shortcut for online or offline queries to the UDDI registry. Figure 2B discloses a 
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flow diagram of the sequence of operational steps for the wireless device's program to replay the 
UDDI registry search strategy. Figure 3B is a network process flow diagram of the interaction of 
the wireless device and the UDDI registry when carrying out the program to replay the UDDI 
registry search strategy. 

The search strategy may also be saved as a quick-hnk for query terms. This is particularly 
advantageous when using various user locations or handles. Since business information tends to 
be location specific, a search retrieving UDDI information for one location (e.g., Europe) may 
result in a null set error for a different location (e.g., United States). Thus, if a user is moving 
from one location to another, the core search terms are re-transmitted with the updated locaton 
information pasted in the user location information field. 

The sequence of operational steps for the wireless device's UDDI registry browsing 
method are shown in Figure 2 A. The Mobile Web Services menu of Figure lA begins by 
initializing the user's location, under the example shown the wireless device is GPS enabled, the 
user has activated the GPS tracking to allow the device to append location coordinates. 
Alternately, the user could enable other means for wireless location (e.g., mobile triangulation 
location), hi the preferred embodiment, however, the device utilizes a single means of location 
at one time.. The user may then indicate a locator tolerance, which serves to filer information 
that is deemed outside the geographical tolerances. The user may further indicate a default 
location for the device or enter a more specific location from which the queries will be entered 
from. In Figure IB, the user indicates to the device that GPS coordinates are automatically 
detected and displayed. 

The menu continues to Figure IC, where the user enters a location handle from which 
the appended locator information may be stored. The location handle may also be instructed to 
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automatically update itself as the user changes locations under the search handle that will be 
associated with the user's search strategy. The user may then enter a search handle that will be 
associated with the user' search strategy. The query terms are subsequently entered by the user, 
which may be a business name, part of a business name, a service description, or other 
characterization. If the characterization is part of a business name, the wireless device then sends 
afindjusiness XML inquiry using Simple Object Access Protocol (SOAP) to the UDDI registry 
with an appended locator. The wireless device then receives back from the UDDI registry, a 
businessList message shown in the Mobile Web Services menu of Figure ID, that contains a Ust 
of business names or organizations satisfying the find_business query which satisfied the locator 
tolerance. The user can then select an item from the returned businessList message and drill- 
down in the selected business' entity data. 

The Mobile Web Services menu of Figure IE shows the wireless device then sendmg a 
find_service XML inquiry using SOAP to the UDDI registry. The Mobile Web Services menu of 
Figure IF shows the wireless device then receiving back from the UDDI registry, a serviceList 
message that contains a list of names of services offered by the selected business. The user can 
then select an item from the returned serviceList message and drill-down in the selected service 
data, as shown by the Mobile Web Services menu of Figure IG. 

The wireless device then sends a _get_serviceDetail_ XML inquiry using SOAP to the 
UDDI registry, as shown by the Mobile Web Services menu of Figure IG. The Mobile Web 
Services menu of Figure IH then shows the wireless device receivmg back from the UDDI 
registry a serviceDetail message that includes bindingTemplate data that contains the details of 
the selected service. Included in the bindingTemplate data is the accessPoint URL, which is the 
URL of the selected service on the web site of the selected business. 
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The Mobile Web Services menu of Figure II shows the wireless device displaying the 
accessPoint URL to the user. The Mobile Web Services menu of Figure 1 J shows that the 
serviceDetail message can contain one or a plurality of URLs, depending on the number of 
matches made against the user's query in the search by the UDDI registry. The wireless device 
also stores the search handle in user profile/preference with the selected accessPoint URL, to 
enable the user to access web pages from the web site of the selected business. This provides the 
user with a shortcut for accessing pages from web sites, in response to the user's entry of 
abbreviated search handle to the wireless device. 

hi addition to the user location, the wireless device also stores the search handle in user 
profile/preference with the UDDI registry search sfrategy. The stored search strategy includes the 
business name query , the selected businessEntity data, the selected businessService data, the 
selected bindingTemplate data, and the selected accessPoint URL. This provides the user with a 
shortcut for online or offline queries to the UDDI registry, in response to the user's entry of 
abbreviated search handle to the wireless device. 

To replay a UDDI registry search strategy, the user enters a search handle into the 
wireless device and selects the replay option, as shown in the Mobile Web Services menu of 
Figure IK. The wireless device then accesses the UDDI registry search strategy from user 
profile corresponding to the search handle and loads the business name query , the selected 
businessEntity data, the selected businessService data, and the selected bindingTemplate data as 
each respective operand that would have been otherwise entered by the user. If the data in the 
UDDI registry has been updated since the user's last query, the bindingTemplate data may 
contain additional or modified accessPoint URLs, of the selected service on the web site of the 
selected business, as shown by the Mobile Web Services menu of Figure IL. Alternately, if the 
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search handle is replayed in a different location, the user may specify a "regional search handle", 
wherein the search handle consists only of query terms, and those terms are subsequently 
retransmitted using the new appended locator. 

Figure 2 is a functional block diagram of the wireless device 100, and illustrates its 
5 various components and programs. Figure 2 discloses the memory 202 connected by means of 
the bus 204 to the radio 206, the keypad 104, the central processor 210 and the display 212. The 
memory 202 contains program modules each consisting of a sequence of programmable 
instructions. The wireless devices UDDI registry browsing program 240 (see Figure 2A) is 
stored in the memory 202. The wireless devices replay UDDI registry search strategy program 
% 270 (see Figure 2B) is also stored in the memory 202. The indirect session thru server program 
n I 220 is also stored in the memory 202. 

User data 222 is stored in the memory 202, which includes the user ID 230, the user 
Ul profile 232, and the user location 233. The user profile 232 includes the user's name and email 
Hj address, the user' s search handles, the UDDI search strategies, the sortmg and filtering 

specifications, selected URLS, selected document titles and binding templates which contain 
URLS. The user location 233 includes the device's GPS location, cell ID location, triangulated 
location, manually entered location and landmark location. Also contained in the memory 202 of 
Figure 2 is the cache 224 wherein documents and lists returned fi-om a website, can be stored, hi 
addition, the WAP client program 108, user location 107, and user profiles/preferences 105 are 
20 stored in the memory 202 . 

Figure 2a is a flow diagram disclosing the sequence of operational steps for the wireless 
device's UDDI registiy browsmg program 240. The steps depicted in Figure 2A are as follows: 
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step 250: WIRELESS DEVICE BROWSING UDDI REGISTRY 
ENTER LOCATION HANDLE "_DC_TRIP_" 
ENTER SEARCH HANDLE "_RESTAURAUNT_" 

Step 252: ENTER QUERY TERMS "_MIDDLE_EAST*_" + "_KABOB_" 
IS THIS A BUSINESS NAME? Y/N "_Y_" 
IS THIS A SERVICE NAME? Y/N "_N_" 

Step 254: SEND "_find_business_" XML INQUIRY WITH SOAP PROTOCOL TO 
UDDI REGISTRY WITH APPENDED LOCATOR 

Step 256: SELECT ITEM FROM RETURNED businessList MESSAGE 
DRILL-DOWN BUSINESS ENTITY DATA 
"_KABOB_EMPORIUM_" 

Step 258: SEND "_find_service_" XML INQUIRY WITH SOAP PROTOCOL TO 
UDDI REGISTRY WITH APPENDED LOCATOR 

Step 260: SELECT ITEM FROM RETURNED serviceList MESSAGE 
DRILL-DOWN BUSINESS SERVICE DATA 
"_MENU_" 

Step 262: SEND "_get_serviceDetaiL" XML INQUIRY WITH SOAP PROTOCOL TO 
UDDI REGISTRY 

Step 264: SELECT ITEM OF RETURNED serviceDetail MESSAGE 
DISPLAY accessPoint URL 
FROM bindingTemplate DATA "MENU" 
IN RETURNED serviceDetail MESSAGE 
URL = "_www.kebabemporium.com\tnenu_" 

Step 266: STORE SEARCH HANDLE "_RESTAURANTS_" IN USER PROFILE 
WITH APPENDED LOCATOR HANDLE "_DC_TRIP_" 
SELECTED URL = "_www.kebabemporium.com\menu_" 

Step 268: STORE SEARCH HANDLE "_RESTAURANT_" WITH APPENDED 
LOCATOR HANDLE IN USER PROFILE WITH UDDI REGISTRY 
SEARCH STRATEGY: 

BUSINESS NAME QUERY "_MIDDLE_EAST*_" + "_KABOB_" 

businessEntity DATA SELECTED "_KABOB EMPORIUMJ' 

businessService DATA SELECTED "_MENU_" 

bindingTemplate DATA SELECTED "_DINNER_" 

accessPoint URL SELECTED "_www.kebabemporium.com\menu\dinner_" 
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Figure 2B shows a flow diagram of the sequence of operational steps for the wireless 
device's program to replay the UDDI registry search strategy. Figure 2B includes the following 
steps: 



Step 271 : REPLAY UDDI REGISTRY SEARCH STRATEGY ENTER SEARCH 
HANDLE "_RESTAURANT_" UTILIZING APPENDED LOCATOR 

Step 272: ACCESS UDDI REGISTRY SEARCH STRATEGY IN USER PROFILE 
FOR SEARCH HANDLE "_RESTAURANT_": 
BUSINESS NAME QUERY "_MIDDLE_EAST*_" + "_KABOB_" 
businessEntity DATA SELECTED "_KABOB_EMPORIUM_" 
businessService DATA SELECTED "_MENU_" 
bindingTemplate DATA SELECTED "_DINNER_" 
accessPoint URL SELECTED "_www.kabobemporium.com\menu\dinner_" 

Step 274: SEND "_find_business_" XML INQUIRY WITH SOAP PROTOCOL TO 
UDDI REGISTRY 

Step 276: SELECT ITEM FROM RETURNED businessList MESSAGE 
DRILL-DOWN BUSINESS ENTITY DATA 
"_KABOB_EMPORIUM_" 

Step 278: SEND "_fmd_service_" XML INQUIRY WITH SOAP PROTOCOL TO 
UDDI REGISTRY 

Step 280: SELECT ITEM FROM RETURNED serviceList MESSAGE 
DRILL-DOWN BUSINESS SERVICE DATA 
"_MENU_" 

Step 282: SEND "^et_serviceDetail_" XML INQUIRY WITH SOAP PROTOCOL TO 
UDDI REGISTRY 

Step 284: SELECT ITEM OF RETURNED serviceDetail MESSAGE 
DISPLAY accessPoint URLs 
FROM bindingTemplate DATA "DINNER" 
IN RETURNED serviceDetail MESSAGE 
URL = "_www.kebabemporium\rsvp\dimier_" 
URL = "_www.kebabemporium\specials\dimier_" 
URL = "_www.kebabemporium\menu\dimier_" 
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Figure 3 A discloses a network process flow diagram showing the interaction of the 
wireless device and the UDDI registry when carrying out the UDDI registry browsing program of 
Figure 2A. The network process flow diagram in Figure 3A consists of three columns labeled 
respectively, wireless device 100, server 140 and UDDI registry 170. The process flow diagram 
Figure 3A illustrates the interaction between steps carried in the wireless device 100 and steps 
carried out in the UDDI registry 170. The diagram of Figure 3A begins with the wireless device 
100 step 300, where the user location is obtained. Next, in step 301 a search handle is entered, 
and query terms are entered. At step 302, the Jind_business_ query is sent with an appended 
locator to the UDDI registry 170. In the UDDI registry column 170 in Figure 3A, the UDDI 
registry conducts searches based on the Jind_business_ query and returns the businessList in 
step 320. The flow then returns to the wireless device 100 and passes to step 303 wherein an 
item of the businessList is selected which typically is a businessEntity. The businessEntity is 
then drilled down. The flow then passes to step 304 in which the Jind_service_ query is sent 
with an appended locator to the UDDI registry. The flow then passes to the UDDI registry 170 
where the Jind_service_ query is searched and the service hst is returned in step 321. Then the 
flow passes to the wireless device 100 where an item of the serviceList is selected which is a 
businessService. The businessService is subsequently drilled down in step 305. The flow 
proceeds to step 306 in which the _get_serviceDetaU_ query is sent to the UDDI registry. Then 
the flow passes to the UDDI registry 170 where the _get_serviceDetail_ query is responded to 
and the binding template is returned in step 263. Then the flow passes back to the wireless 
device 100 wherein the serviceDetail is selected from the bindingTemplate and the accessPoint 
URL is stored. 
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Figure 3B illustrates a network process flow diagram of the interaction of the wireless 
device and the UDDI registry when carrying out a program to replay the UDDI registry search 
strategy. Figure 3B is divided into three colimins, the wireless device column 100, the server 
140 column, and the UDDI registry 170 column. Figure 3B starts with the wireless device 
5 entering the replay UDDI registry search strategy wherein the search/locator handles are entered 
in step 310. Then the process flows to step 311 where the search strategy and/or location is 
accessed in the user profile which corresponds to the search/location handle which was inputted 
in step 310. Figure 3B then proceeds through the remainder of the processes in a similar manner 
as that disclosed in Figure 3A. 
■Jo Figure 3B discloses how the user is enabled to replay a prior UDDI registry search 

li 1 strategy using the same locator handle. The user merely enters a previously used search handle 
into the wireless device and selects the replay option. The wireless device then accesses the 
UDDI registry search strategy from the user's stored profile corresponding to that search handle. 
!J! This may be performed either at the wu:eless device 100 or, in the aUemate embodiment m the 
^\ 5 server 140. The search strategy includes information such as the husinessEntity data and 

businessService data and bindingTemplate data that was found during the course of an earUer 
search of the UDDI registry 170. This data contained in the UDDI registry search strategy 
(accessed from the stored profile) is then loaded as the data for each respective operand that 
would have been otherwise entered by the user, hi this way, the flow diagram of Figure 3B 
20 enables the user to automatically invoke a search strategy of the UDDI registry 170, that was 
used in the past. A discussed above, the replay of a search strategy under a different locator 
handle embodies the process of Figures 3 A and 3B, wherein the "regional search strategy" 
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invokes query terms with a newly appended location. The query terms are sent according to 
Figure 3 A to return the new location search information. 

Figure 4 is a functional block diagram of the knowledge engine server, showing the 
memory storing the application services software programs needed to perform the operations of 
5 an embodiment of the invention. Figure 4 discloses the functional components of an exemplary 
knowledge engine server 140 arranged as an object model. The object model groups the object 
oriented software programs into components that perform the major functions and appUcations in 
knowledge engine server 140. The object model for memory 402 of knowledge engine server 
140 employs a three-tier architecture that includes presentation tier 415, infrastructure objects 
K) partition 422, and business logic tier 414. The object model further divides business logic tier 
flj 414 into two partitions, apphcation objects partition 422 and data objects partition 426. 
^4 Presentation tier 415 retains the programs that manage the device interfaces to knowledge 

f; engine server 140. In Figure 4, presentation tier 415 includes network interface 420. A suitable 
n implementation of presentation tier 415 may use Java servlets to interact with WAP protocol 
15 gateway 120 via the hypertext transfer protocol ("HTTP"). The Java servlets run within a 

request/response server that manages the exchange of messages between WAP protocol gateway 
120 and knowledge engine server 140. A Java servlet is a Java program that runs within a Web 
server environment, A Java servlet takes a request as input, parses the data, performs logic 
operations, and issues a response back to WAP protocol gateway 120. The Java runtime 
20 platform pools the Java servlets to simultaneously service many requests. Network interface 420 
accepts request messages from WAP protocol gateway 120 and passes the information in the 
request to visit object 428 for further processing. Visit object 428 passes the result of that 

processing to network interface 420 for transmission back to the WAP protocol gateway 120. 
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Network interface 420 may also use network adapter 406 to excahnge data with another user 
device. 

Infrastructure objects partition 422 retains the programs that perform administrative and 
system functions on behalf of business logic tier 414. hifrastructure objects partition 422 
5 includes operating system 425, and an object oriented software program component for database 
server interface 430, and system administrator interface 432. 

Business logic tier 414 in Figure 4 includes multiple instances of visit object 428, 428', 
428". A separate instance of visit object 428 exists for each network interface 420 session. Each 
visit object 428 is a stateful session bean that includes a persistent storage area from initiation 
^ lo through termination of the session, and not just during a single interaction or method call. The 
fi I persistent storage area retains information associated with the session. 
.3 " When WAP protocol gateway 120 sends a query message to knowledge engine server 

140, the message is sent to network interface 420 to invoke a method that creates visit object 428 
if? and stores connection information as a state in visit object 428. Visit object 428 may, in turn, 
5 invoke a method in UDDI registry browsing application 440 to browse the UDDI registry 170. 
Apphcation 440 sends queries to the UDDI registry, as discussed above. 

When WAP protocol gateway 120 sends a search and/or location handle message to 
knowledge engine server 140, a message is sent to network interface 420 to invoke a method that 
creates visit object 428 and stores connection information as a state in visit object 428. Visit 
20 object 428 may, in turn, invoke a method in replay UDDI registry search strategy or location 

application 442 to replay a prior search strategy. The apphcation 442 perforais the replay method 
discussed above. Similar operations occur for apphcations 444, 446 and 448 in Figure 4. 
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Figure 4A is a more detailed functional block diagram of the server, showing the 
knowledge engine 142. The knowledge engine 142 includes a program which is shown in 
Figure 4A as a sequence of steps 1 through 13. 



5 KNOWLEDGE ENGINE 142 

[1] RECEIVE USER'S QUERY OR SEARCH HANDLE WITH USER LOCATION 

HANDLE OR APPENDED LOCATOR 
[2] IF SEARCH/LOCATOR HANDLE RECEIVED, THEN REPLAY UDDI SEARCH 
10 PROFILE & GOTO 7 

[3] RECEIVE AND STORE/CACHE USER LOCATION OR STATUS 

0 [3] ACCESS UDDI REGISTRY WITH USER'S QUERY TO IDENTIFY WEB SITES 

1 USING APPENDED LOCATOR 

iM [4] RETURN LIST OF WEB SITES TO USER AND STORE QUERY AND BINDING 

% TEMPLATES IN PROFILE 

;i [5] RECEIVE USER'S SELECTION OF WEB SITES TO SEARCH & UPDATE USER 

H! PROFILE 

Ij [6] SEARCH THE IDENTIFIED WEB SITES USING URLS FROM BINDING 

TEMPLATES 

m [7] RETRIEVE DOCUMENTS RESULTING FROM SEARCH 

1J1 [8] SORT UST OF DOCUMENTS IN ACCORDANCE WITH USER'S PROFILES 

1=^ [9] STORE DOCUMENTS AND LIST IN CACHE 

y] [ 1 0] RETURN UST OF DOCUMENTS TO USER WHENEVER USER IS LOGGED 

U ON 

^5 [11] RECEIVE USER'S SELECTIONS FROM LIST AND UPDATE USER'S PROFILE 

AND/OR LOCATION 
[12] RETURN SELECTED DOCUMENTS TO USER 

[13] ASSOCL\TE SEARCH HANDLE WITH USER'S SELECTIONS IN USER'S 
PROFILE 

30 

Also provided in server 140 is the user data 146 which includes the user ID profile 230 
which is discussed above. Since a plurality of users may make use of the server 140, there are a 
plurahty of user profiles shown in Figure 4A, one for the user ID 230' having user profile 232' 
and another for the user ID 230" havmg user profile 232". The server 140 of Figure 4A also has 
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a cache 144 which stores documents and Usts which are obtained from the various websites 160 
that have been interrogated by the user with the aid of the server 140. 

Figure 4B is a flow diagram of the sequence of operational steps for the server 140 UDDI 
registry browsing program 170. Figure 4B has three colunms, the furst column labeled user's 
5 wireless device 100, the second column labeled server 140, and a third column labeled UDDI 
registry 170 and web sites 160. Figure 4B illustrates the interaction of the wireless device 100, 
the server 140, the UDDI registry 170 and the web sites 160, in accordance with an embodiment 
of the invention. Starting with the user's wireless device 100, Figure 4B receiving a user 
location 400, and subsequently sending a query to the server, in step 401 . At the server 140, the 
% location-specific query is received from the user in step 402, and the process flows to step 403 
n I where web sites are identified from the UDDI registry and the user' s profile is updated. The 
process in step 403 for identification of the web sites from the UDDI registry is the process 
^ which has been discussed above in connection with Figures 2A and 3A. The process then flows 
y] to step 410 in the UDDI registry 170, wherein the UDDI registry accesses the requested 
"'Is information in response to the queries sent from the server 140 to identify web sites. Step 410 
then transfers the results of that search from the UDDI registry 170 back to the server 140. At 
the server 140, the process flows to step 404 wherein the server has taken the information 
identifying the web sites received from the UDDI registry 170, and formulates a request to 
retrieve documents which is sent to the web sites 160. The process then flows to step 411 where 
20 the web sites 160 receiving the request from the server 140, access their respective severs for the 
requested documents and then return the documents to the server 140. The server 140 then sorts 
the documents into a hst in accord with the user's profile/preferences, sorting the list into the 
order requested by the user (e.g. closest proximity to location), and filtering out any documents 
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which the user is not interested, in accordance with the user's profile. The process then flows to 
step 405 in which the documents are stored in the cache at the server, cache 144, and the list 
which has been sorted by the server 140, is returned to the user. The process then flows to step 
406 at the user's wireless device 100 where the sorted list received from the server 140 is 
5 presented to the user and the user can select from that hst those documents desired to be 

reviewed. In step 406, the user's request for documents is then sent back to the server 140. The 
process then flows to step 407 where the server 140 accesses its cache 144 to retrieve those 
documents selected by the user in step 406, and then the server 140 returns the selected 
documents to the user's wireless device 100. Step 407 then compiles the user's preferences in 
^lib the user profile. The server 140 can also update the user's preferences in the user's profile in 
Yii step 409. The process flows from step 407 to step 408 at the user's wireless device 100, where 
the user receives the selected documents. 

hi an alternate embodiment. Figure 5 globally illustrates location based service discovery 
%l in Web services and ad-hoc networking environments (UBICOMM, intranet home/ofice 
15 networks, etc.). Figure 5 discloses the communication between the Intemet Domain 510, 
Cellular Network Domain (2G/3G access/core networks), 510, the Ad-Hoc Network Domain 
530, and the user handset 540. The Intemet Domain 510 consists of discovery services 511, 
distribution services512 and description services 513, in which the hitemet Domain 510 
communicates to the Cellular Network 510 and user handset 540. Similarly, the disclosed Ad 
20 Hoc Domain 530 also consists of Description 531, Distribution 532, and Discovery 533 services 
that are communicatively coupled to the handset 540. 

The discovery (511, 546, 533) and distribution (512, 545, 532) services in the system are 

communicatively linked, wherein an optional distribution SOAP/SYNCML proxy 525 may be 
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implemented in the Cellular Network 510. The Cellular Network 510 further comprises of a 
location server 521, a Cell Identification 523, an Assisting Global Positioning System (A-GPS) 
522, and a Mobile-Based Enhanced Observed Time Difference (E-OTD) 524. These elements 
serve to help identify locations and/or positions of the handset 540 during operation under the 
5 present invention.. 

The handset 540 is also enabled with A-GPS 541 and E-OTD 543, both of which 
communicate to the Cellular Network 510 and to the handset location server 544. Additionally, 
the handset 540 can be equipped with BluetoothTM/Local Positioning (BT/LP) capabiUties 542. 
fl The BT/LP capabilities further allow the vidreless handset to establish a user location that may be 
% utilized for queries, discussed above. The User hiterface (UI) 547 and Apphcation Programs 548 
n \ are also communicatively coupled to the handset distribution services 545. The service discovery 

agent typically communicates through the location server 521, hitemet Domain Discovery 511, 
iJI handset Location Server 544 and Discovery 546 (indicated in dashed lines). The remainder of 
B the communicative links are enabled to transfer location between service discovery agents. 
"Ts Figure 6 discloses an alternate embodiment and illustrates location standardization in a 

network framework. In Figure 6, a server 600, a network 622, and a terminal 622 are disclosed. 
The server 600 comprises three levels of software and locator services: content 610, 
portals/applications 611 and middleware 612. The content 610 will typically consist of map 
location and map information service and/or databases (MAP/GIS) 601. The map information 
20 601 communicates to the portals/appUcations 611 under an open GIS consortium (e.g. 

MapquesfTM). Additionally, other content 602 maybe included or added (e.g., white pages, 
yellow pages, etc.). The content may be accessed through UDDI, where the queries may be 
further accessed to the portals/applications 611. hi the portals/apphcations 611, information 603 
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such as fleet management, presence or enhanced alarm calls with locator information (E112 = 
Europe; E91 1 = U.S.) may be located. The information 603 if communicatively coupled to a 
gateway mobile location center (GMLC) or Nokia Artus™ location server 607. The enhanced 
alarm calls with locator information (604) are typically in communication with a mobile 
5 positioning center (MPC) 608, located in the middleware 612. A WAP-GW 606 application is 
further locate in the server middleware 612. 

The network 622 is shown as having two layers, namely the core 623 and access 624 
layers. The core 623 typically consists of a Global System for Mobile Communications 
(GSM)/General Packet Radio Service core 613, a 3''' Generation Packet Switched (PS)/Cuxuit 
% Switched (CS) core 614 and an hiterim Standard 41 (IS-41) signaling protocol core 615. The 
llj access layer 624 consists of a GSM Base Station System (BSS) 616, GSM/EDGE Radio Access 
Network GERAN 617, Radio Access Network (RAN) 618, IS-136 BSS 619, IS-95BSS 620 and 
H: a Bluetooth™ connection 621. 

!i] The terminal partition 622 is disclosed as having layers for the terminal 623, and terminal 

'1 5 applications 624. The terminal 623 layer consists of E-OTD 625, A-GPS 626, a 3^' generation 
location method (IP-DL) 627, as well as a Bluetooth™ protocol 628, which is communication 
with the access layer's 624 Bluetooth™ connection 621 of network 622.. The terminal 
appUcations include a WAP browser 629, which communicates to the information 603 contained 
in the portals/applications layer 611 of server 600. The terminal apphcation further include 
20 EPOC Apphcations 630 (Symbian™ operating system). User hiterface-Based Applications 631 , 
JAVA applets 632, and an HTTP browser 633, which is communicatively coupled to the WWW 
605 in Server 600. 
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Through the system disclosed above, the user may select location information that is 
pasted/appended to the service discovery message. As ahready discussed the user's location may 
be determined through A-GPS, GPS, E-OTD, or other methods. The wireless device will be 
enabled with software that will include the user location/coordinates. If the location is executed 
5 through the network, the user may use the "Loc" button (and associated function) to include 
location information in the service discovery message. The subsequently received information 
would then be filtered accordingly. The location information can also be received from a 
Bluetooth™ device in which specific locations maybe predefined. Thus, information from the 
ii BluetoothTM (ievice will be beamed to the mobile device in a Bluetooth™ message into the 
% service discovery message. The location information may be in the form of CI, GPS info, E- 
! OTD, etc., or may even have the name of a unique place (e.g. Statue of Liberty). 

It is understood that under the aforementioned embodiments, the term "document" may 
ijl accompany elements and infr>rmation other than web page text. While one type of usage under 
y] the present invention encompasses text searching, the service searched with UDDI may include 
4 5 other services, such as sfreaming audio, video, or other application-specific communication. 

Furthermore, alternate embodiments of the present invention may include location "nests", where 
location searches can start in a broad geographical region, and may be subsequently narrowed by 
the user. 

Although illusfrative embodiments have been described herein in detail, it should be 
20 noted and understood that the descriptions and drawings have been provided for purposes of 

illusfration only and that other variations both in form and detail can be made thereupon without 
departing from the spirit and scope of the invention. The terms and expressions have been used 
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as terms of description and not terms of limitation. There is no limitation to use the terms or 
expressions to exclude any equivalents of features shown and described or portions thereof. 
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